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Intellectual Property Rights 

IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http ://webapp . etsi .org/IPR/home . asp ) . 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by ETSI Technical Committee Satellite Earth Stations and 
Systems (SES). 



Introduction 

The Next Generation Network (NGN) is seen as the future universal network based on IP into which different network 
technologies will be integrated. The BSM network [1] is an example of one of these technologies. Working groups at 
ETSI (TISPAN), ITU and others (3GPP, TMF etc) have defined many of the functional characteristics of the NGN [4], 
[8], [9] and their work is continuing. 

The BSM network has been defined with many of the same features (IP protocol based packetised transport, modular 
and interoperable control plane elements, a largely access agnostic architecture, etc.) necessary for compatibility with 
the NGN. Hence the BSM network is a candidate for NGN integration. 

The BSM system has also been defined as a functional architecture to implement IP-based services in a standardised 
way over a variety of satellite technologies, and with the potential to operate these services when the BSM network is 
integrated into heterogeneous networks [i.l], [i.2]. The BSM architecture is characterised by the SI-SAP which defines 
the separation between common Satellite-Independent (SI) protocol layers and alternative lower Satellite-Dependent 
(SD) layers [2]. In addition, interfaces with higher-layer protocols and peer external networks and customer equipment 
are provided where appropriate. This is also very compatible with the NGN architecture which wants to clearly 
distinguish between transport specific and service specific functions. 

One of the main functional building blocks of the NGN is the IP Multimedia Subsystem (IMS) [6]. The IMS provides a 
means initially for fixed-mobile and now many network convergence and interworking functionality for IP-based 
services. These include today IPTV, fixed and mobile voice and presence, and potential new services like video 
conferencing, peer-peer gaming etc. in the future. The definition of the NGN and the specifications of the IMS core 
functionality are still evolving in the standards bodies, but are sufficiently mature and stable to be able to define the 
potential interactions with the BSM network. Basic BSM network services could be deployed over the current IMS, but 
as IMS-based networks and applications mature, converged BSM services can be offered in conjunction with other 
satellite and terrestrial wireline and wireless networks using a common subscriber management system and control 
plane. 

The present document will specify how BSM networks can be integrated into the NGN architecture. 
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1 Scope 

The integration and interoperability of BSM networks with the NGN is specified in terms of the functional architecture 
and associated functions and interfaces. 

The present document is based on and uses TISPAN (release 2) definitions and terminology (since TISPAN release 3 is 
not yet fully specified). 



2 References 

References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the 
reference document (including any amendments) applies. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are necessary for the application of the present document. 

[1] ETSI TS 102 292: "Satelhte Earth Stations and Systems (SES); Broadband Satellite Multimedia 

(BSM) services and architectures; Functional architecture for IP interworking with BSM 
networks". 

[2] ETSI TS 102 357: "Satelhte Earth Stations and Systems (SES); Broadband Satellite Multimedia 

(BSM); Common Air interface specification; Satellite Independent Service Access Point SI-SAP". 

[3] ETSI TS 102 462: "Satelhte Earth Stations and Systems (SES); Broadband Satellite Multimedia 

(BSM); QoS Functional Architecture". 

[4] ETSI TS 102 672: "Satelhte Earth Stations and Systems (SES); Broadband Satellite Multimedia 

(BSM); Management Functional Architecture". 

[5] ETSI ES 282 001: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN);NGN Functional Architecture". 

[6] ETSI ES 282 007: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); IP Multimedia Subsystem (IMS); Functional architecture". 

[7] ITU-T Recommendation Y.1291: "An architectural framework for support of Quality of Service in 

packet networks". 

[8] ITU-T Recommendation Y.201 1: "General principles and general reference model for NGN". 

[9] ITU-T Recommendation Y.2012: "Functional requirements and architecture of NGN release 1". 

2.2 Informative references 

The following referenced documents are not necessary for the application of the present document but they assist the 
user with regard to a particular subject area. 

[i.l] ETSI TR 101 984: "Satelhte Earth Stations and Systems (SES); Broadband Satellite Multimedia 

(BSM); Services and architectures". 
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[i.2] ETSI TR 101 985: "SatelUte Earth Stations and Systems (SES); Broadband Satellite Multimedia; 

IP over Satellite". 

[i.3] ETSI TR 180 000: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); NGN Terminology". 

[i.4] ETSI TS 123 002: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); LTE; Network architecture (3GPP TS 23.002)". 

[i.5] IETF RFC 3261: "Session Initiation Protocol". 

[i.6] IETF RFC 3320: "SignaUing Compression (SIGCOMP)". 

[i.7] IETF RFC 5049: "Applying Signaling Compression (SigComp) to the Session Initiation Protocol 

(SIP)". 



3 Definitions and abbreviations 
3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

architecture: abstract representation of a communications system 

NOTE: Three complementary types of architecture are defined: 

Functional Architecture: the discrete functional elements of the system and the associated logical 
interfaces. 

Network Architecture: the discrete physical (network) elements of the system and the associated 
physical interfaces. 

Protocol Architecture: the protocol stacks involved in the operation of the system and the 
associated peering relationships. 

BSM Network: BSM subnetwork together with the BSM interworking and adaptation functions that are required to 
provide IP interfaces (i.e. layer 3 and below) to attached networks 

BSM Subnetwork: all the BSM network elements below the Satellite Independent Service Access Point (SI-SAP) 

BSM System (BSMS): BSM System comprises a BSM Network together with the NMC and NCC plus any additional 
elements that are required to provide the network services to the subscribers and their users 

Connectivity-oriented Interconnection (Coix): physical and logical Unking of carriers and service providers based on 
simple IP connectivity irrespective of the levels of interoperabihty 

control plane: plane that has a layered structure and performs the call control and cormection control functions; it deals 
with the signalling necessary to set up, supervise and release calls and connections 

flow (of IP packets): traffic associated with a given connection-oriented, or connectionless, packet sequence having the 
same 5-luple of source address, destination address. Source Port, Destination Port, and Protocol type 

forwarding: process of relaying a packet from source to destination through intermediate network segments and nodes 

NOTE: The forwarding decision is based on information that is already available in the routing table. The 
decision on how to construct that routing table is the routing decision. 

IP Television (IPTV): operator controlled IP based TV service 

NOTE: IPTV is a cable/satellite replacement service that uses multicast over a private IP network. 

network Control Centre: equipment at OSI Layer 2 that controls the access of terminals to a satellite network, 
including element management and resource management functionality 
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Next Generation Network (NGN): packet-based network able to provide services including Telecommunication 
Services and able to make use of multiple broadband, QoS -enabled transport technologies and in which service-related 
functions are independent from underlying transport-related technologies 

NOTE: It offers unrestricted access by users to different service providers. It supports generalized mobility, 
which will allow consistent and ubiquitous provision of services to users. See ETSI [i.3] and ITU [7]. 

new generation networls: See Next Generation Network. 

nomadicity: device that is not fixed but is not continuously mobile 

NOTE: A nomadic devices changes locations but tends to stay at a new location for an extended amount of time. 
Examples include laptops and netbooks. 

Over-The-Top (OTT): IP based video sent on the public Internet without operator control 

Service-oriented Interconnection (Soix): physical and logical Unking of NGN domains that allows carriers and 
service providers to offer services over NGN (i.e. IMS and PES) platforms with control and signalling (i.e. session- 
based), which provide defined levels of interoperability 

user plane: plane that has a layered structure and provides user information transfer, along with associated controls 
(e.g. flow control, recovery from errors, etc.) 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

(NGN)-GETS Government Emergency Telecommunications Services (NGN is GETS with NGN) 
(x)DSL Digital Subscriber Line 



NOTE: X means the different _^avoMrs of DSL. 



3GPP 


3"* Generation Partnership Project 


AF 


Access Function 


AMF 


Access Management Function 


A-RACF 


Access-Resource Admission Control Function 


ARE 


Access Relay Function 


AS 


Application Servers 


ASF 


Application Server Function 


BGCF 


Breakout Gateway Control Function 


BGF 


Border Gateway Function 


BMAC 


BSM Multicast Access Control 


BSM 


Broadband Satellite Multimedia 


BSMN 


BSM Network 


BSMS 


BSM System 


BTF 


Basic Transport Function 


CAMEL 


Call Management Language (TISPAN) 


CLF 


Connectivity session Location and repository Function 


CNG 


Customer Network Gateway 


CNGCF 


CNG Configuration Function 


CoIx 


Connectivity Oriented Interconnection (TISPAN) 


CPE 


Consumer Premise Equipment 


CPN 


Customer Premises Network 


CSCF 


Call Server Control Function 


DHCP 


Dynamic Host Configuration Protocol 


DNS 


Domain Name Service 


FoIP 


Fax over IP 


FSS 


Fixed Satellite Services 


GETS 


Government Emergency Telecommunications Services 


GW 


Gateway 


HSS 


Home Subscriber Server 


IBCF 


Interconnection Border Control Fimction 


I-CSCF 


Interrogating CSCF 
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ID 


IDentity 


IETF 


Internet Engineering Task Force 


IMS 


Internet Multimedia Subsystem 


IMS-AF 


(IMS) Application Function 


IMS-SD 


(IMS) Service Discovery 


IP 


Internet Protocol 


IPTV 


Internet Protocol Television 


IPTV 


Internet Television 


IPv4 


Internet Protocol version 4 


IPv6 


Internet Protocol version 6 


ISC 


IMS Service Control 


ISP 


Internet Service Provider 


IWF 


Interworking Function 


M2M 


Machine to Machine 


MAC 


Medium Access Control 


MGCP 


Media Gateway Controller Function 


MGF 


Media Gateway Function 


MOW 


Media GateWay 


MRFP 


Media Resource Function Processor 


NACF 


Network Access Configuration Fvmction 


NAS 


Network Access Server 


NASS 


Network Attachment Subsystem 


NAT 


Network Access Translation 


NCC 


Network Control Centre 


NGN 


Next Generation Network 


NGN 


Next Generation Network or New Generation Network 


NMC 


Network Management Centre 


NOC 


Network Operation Centre 


NSS 


Network Support System 


OBP 


On-Board Processing 


OSA 


Open Service Access (3GPP) 


OSS 


Operational Support System 


OTT 


Over the Top 


PBNM 


Policy Based network Management 


PCRF 


PoUcy and Charging Rule Function 


P-CSCF 


Proxy CSCF 


PDBF 


Profile Data Base Function 


PDP 


Policy Decision Point 


PES 


Policy Enforcement Subsystem 


PPP 


Point-to-Point Protocol 


PSTN 


Public Switched Telephone Network 


QID 


Queue Identifier 


QOE 


Quality of Experience 


QoS 


Quahty of Service 


RACS 


Resource and Admission Control Subsystem 


RCEF 


Resource Control Enforcement Function 


RTP 


Real Time Protocol 


SEP 


Service-Based Policy control 


S-CSCF 


Serving CSCF 


SD 


Satellite Dependent 


SDAF 


Satellite Dependent Adaptation Functions 


SDP 


Session Description Protocol 


SGF 


Signalling Gateway Function 


SI 


SatelUte Independent 


SIAF 


Satellite Independent Adaptation Functions 


SIP 


Session Initiation Protocol 


SI-SAP 


SatelUte Independent Service Access Point 


SI-SAP 


SatelUte Independent Service Access Point 


SLF 


Subscription Locator Function 


SOIX 


Service Oriented Interconnection (TISPAN) 


SPDF 


Service-based Policy Decision Function 


ST 


SatelUte Terminal 
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STB 

TETRA 

TISPAN 



Set-top Box 

Terrestrial Trunked Radio 

Telecommunications and Internet converged Services and Protocols for Advanced Networking 

Telecommunications Management Forum 

Time to live (protocol timer) 

User Authentication and Authorization Function 

User Datagram Protocol 

Use Equipment 

User Profile Server Function 

Uniform Resource Identifier 

User Terminal 

Voice over IP 

"Anything" over IP 



TMF 
TTL 

UAAF 

UDP 

UE 

UPSF 

URI 

UT 

VoIP 

XoIP 



4 



NGN Impacts on BSM Networks 



4.1 



Background 



The Next Generation Network (NGN) is intended to support a set of assured (and best-effort) end-to-end services over a 
network composed of heterogeneous sub-networks, and based on the Internet Protocol (IP). 

One of the main characteristics of the NGN architecture is the uncoupling of services and underlying transport functions 
(i.e. network technologies), allowing services and transport to be offered separately and to evolve independently. 
Therefore in the NGN architectures there is a clear separation between the functions for services and for networks, and 
open interfaces are provided between them. Provisioning of existing and new services can then be independent of the 
transport network and the access technology. In addition the "external" network services are allowed to use their native 
protocols as was specified in the NGN architecture and interwork with other networks over standardised interfaces and 
interworking modules. This facilitates the inclusion of more networks, from cable to 4G, within the NGN infrastructure. 
The approach adopted by the NGN is shown in figure 4.1. 

Other characteristics of the NGN defined by TISPAN concern the management of overall services and networks 
(Network Management) through an Operational Support System (OSS). The BSM features required for compatibility 
with the NGN OSS have been defined in the TS 102 672 [4] on BSM Management and will not be expanded further 
here. 

ITU-T (SG-13), ETSI (TISPAN), IETF and 3GPP have defined NGN networks and services and the work on this 
subject is continuing (see the informative reference list). There are differences between the details of NGN definitions 
(including architectures) of the standards organisations; for example, ES 282 007 [6] on the Core IMS Functionality of 
TISPAN is a subset of the 3GPP UMTS Architecture defined in TS 123 002 [i.4] and is restricted to session control 
functionaUties. In turn the TISPAN session control was adopted by 3GPP. 

See annex A for further details of the IMS architecture. 

The core IMS excludes Application Servers (AS) that host Access Functions (AF) and transport/media related functions 
such as the Multimedia Resource Function Processors (MRFP) and the IMS Media Gateway function (IMS-MGW) that 
are service or network specific. Nevertheless, there is a specific set of features and generally common understanding 
and convergence across the core functionality, and much of the work on standards is being pursued under the 
responsibility of the ETSI TISPAN WG. In the present document the TISPAN definitions and terminology for NGN are 
used. Furthermore the present document is based on the TISPAN release 2 specifications as the BSM system does not 
address all issues of mobility. 
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Figure 4.1 : NGN Application & Transport Strata 



4.2 NGN Network Architecture 

Figure 4.2 shows a combined physical and functional overview of the NGN network as defined by ES 282 001 [5] 
(NGN Functional Architecture). In the figure the BSM network may take the place of an access transport function 
(network). 

The functional entities that make up a subsystem may be distributed over network/service provider domains. 
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Figure 4.2: NGN Functional Architecture 
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4.2.1 Service Stratum 

The NGN needs to support a wide variety of application services. In the Service Stratum therefore, while IMS (see 
annex A for a description) is at the heart of all emerging NGN standards, it is just one of a number of Service Control 
Subsystems. Examples of other Service Control Subsystems include for example PSTN emulation (PES) and streaming 
services. The IMS was intended for control and delivery of real-time conversational services using SIP-based signalling 

but has evolved to support other services like advanced IPTV that require service convergence and nomadicity. The 
Service Stratum subsystems that support nomadicity may be distributed between visited and home networks. 

In addition to the Service Control Subsystem, the Service Stratum includes a number of common functional entities that 
can be accessed by more than one subsystem. These include the: 

• User Profile Server Function (UPSF) for common identity management. 

• Subscription Locator Function (SLF) for mobile users. 

• Application Server Function (ASF) for specific apphcations. 

• Interworking Function (IWF) to integrate legacy networks. 

4.2.2 Transport Stratum 

IP-connectivity is provided to the NGN customer equipment and to other networks by the Transport Stratum. This 
transport layer comprises a Transport Control Sublayer on top of transport processing functions in the access and core 
networks. Equivalent functions should exist in the User Equipment. 

4.2.2.1 Transport Control Sublayer 

The Transport Control Sublayer is further divided in two subsystems that work closely together: 

• Network Attachment Subsystem (NASS): 

Manages all aspect of network attachment such as IP address provisioning (e.g. DHCP), network level 
user authentication, authorisation of network access and access network configuration. 

• Resource and Admission Control Subsystem (RACS): 

In charge of admission control, resource reservation, policy control and NAT traversal. 

These two subsystems also provide connmon interfaces to the Service Stratum for any transport technology used in 
access and core networks below the IP layer. 

• The RACS provides dynamic policy-based resource control to deliver the QoS required by applications as well 
as address mediation and border control capabihties. 

• And as mentioned above, the NASS provides attachment control, such as authentication, authorization, and 

assignment of IP addresses. 

The NASS and RACS functions may be logically distributed between access and core networks, and between visited 
and home networks. 

Customer interfaces are supported by both physical and functional (control) interfaces, and both are shown in figiu'e 4.2. 
No assumptions are made about the diverse customer interfaces and customer networks that may be connected to the 
NGN access network. All categories of customer equipment are supported in the NGN, from single-line legacy 
telephones to complex corporate networks and are managed by discovery mechanisms and SIP messaging. Customer 
equipment may be both mobile and fixed. 

Physical transport networks provide the connectivity for all components and physically separated functions within the 
NGN. Transport is divided into Access Networks and Core Network, with a Border Gateway Unking the two transport 
network categories. 
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The NGN interface(s) to other networks includes many existing networks, such as the PSTN/ISDN, other NGN, 3GPP 
networks, the PubHc Internet, etc. These interfaces generally employ border gateways at both control and transport 
levels. Border gateways may include access to media transcoding capabilities and bearer adaptation. Interactions 
between the control and transport functions may take place directly or through the RACS functionality. 

4.2.2.2 Transport Processing Functions 

Transport processing functions in the access and core networks include functions supporting packet forwarding and 
routing. These are: 

• Media Gateway Function (MGF): 

The MGF is a translation service that handling the disparate telecommunications networks over the NGN 
especially transcoding/mapping between IP and legacy circuit- switched networks. 

• Border Gateway Function (BGF): 

The BGF provides media relay for hiding endpoint addresses and prevent bandwidth theft as well as 
allowing network access translation and acts as a relay between 2 IP transport domains. 

• Resource Control Enforcement Function (RCEF): 

The RCEF implement policy based resource management based on QoS requirements of attached 
networks. 

• Access Relay Function (ARE): 

The ARE is a relay between user equipment and the NASS; it can insert local configuration information 
before forwarding a request to the NASS. 

• SignalUng Gateway Function (SGF): 

The SGF converts SS7 signalling to IP-based signalling (like SIP). 

• Media Resource Function Processor (MRFP): 

Provides specific media capabilities hke announcements and conferencing as well as interactive voice 
response. 

• Access Management Function (AMF): 

The AMF provides an interface between an access network and the NGN access control functions. 

• Basic Transport Function (BTF): 

The BTF (also Bearer Transport Function) acts as the bearer function for data and media traffic. 
A number of these functions relate to legacy network integration. See annex A for more details. 

4.3 Service requirements 

4.3.1 General NGN Service Requirements 

Apart from the "fundamental capabilities" described above namely packet-based transfer, separation of control 
functions and support for a wide range of services, other capabilities offered by the NGN architecture are summarised in 
table 4.1. 
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Table 4.1 : NGN capabilities 



Capability 


Description 


Subscriber Nomadicity 


Decoupling the subscriber from specific access and specific terminal equipment 


Application Ubiquity 


Application availability from any access network. Content 'tuning' to match 
access & terminal capabilities 


Resource Control 


Authorization & Availability 

Accounting: measuring resource usage, revenue assurance 
Policing resource usage; fraud prevention 


Subscriber Identity & Authentication 


Common Model for all devices, access & applications 


Service Blending 


Service Brokering enables applications to provide adaptive behaviours based 
upon subscriber events and states 


Billing and Settlement Mechanisms 


Especially beneficial for scenarios crossing multiple providers boundaries. 



In the NGN architecture, because of network heterogeneity, network service providers need to perform additional tasks 
during the establishment of Intemet sessions. These tasks are not conveniently or easily carried out by the apphcation 
components themselves. They include application selection and routing services, session authorization services, session 
monitoring services, session detail recording and bilhng, network resource and admission control services, and 
integration of complimentary applications or services. 

Accordingly, the Session Initiation Protocol (SIP) is becoming more widely used as a common mechanism for 
establishing sessions of all kinds. SIP has also become the standard session establishment for IMS. SIP based signalling 
is now standard across policy management elements and is widely used in the RACS architecture for call and resource 
management. In addition, the TISPAN release 2 [4] contains specifications that allows discovery of devices and 
networks that use SIP messaging. As a text-based protocol however SIP can lead to large signalling messages and there 
are many mechanisms envisaged for their compression over bottleneck resomces especially in wireless network (e.g. 
RFC 5049 [i.7]). 

4.3.2 BSM-Specific Service Requirements 

In order to better identify how and where the NGN architecture and IMS functions a number of use cases are described 
in this clause. While representative how offered services they are illustrative in nature and of course not a 
comprehensive list. 

a) VOIP and convergence; 

b) IPTV and IP video: 

Live/Unear TV; 

Video on Demand (VoD); 

c) Emergency/Disaster Services; 

d) Smart Grid/ telemetry. 

4.3.2.1 VOIP and convergence 

This is the traditional NGN/IMS service and the impetus behind the original architecture. For the BSM network, which 
is already all-IP the use of NGN/IMS for voice services completely decouples the BSM network transport from the 
VOIP service. For example when a VOIP device registers on the VOIP service via the IMS core the Session Description 
Protocol (SDP) part of the message announces the specifics of the device for the transmission including admissible rates 
and codecs. Hence while the BSM operator needs to deal with bandwidth requirements, the device specific codecs can 
be managed at the IMS level. Since those are the most likely to differ greatly from one offering to another, taking these 
out of the satelUte operations into the terrestrial network is advantageous. Also using existing gateways, a 
BSM-terrestrial-mobile VOIP offering could easily profit from subscriber management and operator federation offered 
in the IMS core, even interfacing with Public Switched Telephone Networks in areas where legacy services are still 
dominant, an advantage for emergency services (see details below). In addition the provision of a native VOIP service 
over BSM may allow standard techniques to be adopted such as SIP compression, voice activity detection and QoS. 
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4.3.2.2 IPTV and IP video 

Current IPTV offerings are based on broadband wireline networks most often Digital Subscriber lines (xDSL), But the 
expansion of IPTV into underserved areas requires the use of Fixed Satellite Services (FSS) and hence the BSM 
networks. In addition, BSM networks will most Ukely see an upsurge of over the top (OTT) IP video services in the 
next few years. For the BSM operator both IPTV (operator controlled) and OTT IP video will look similar in terms of 
transport but the business model could be different depending on the relationship of the IPTV operator or the OTT 
provider with the BSM operator. In addition, the use of cell phone and smartphones for IPTV interactivity is gaining 
more and more momentum and should be factored in any BSM IPTV scenario and provide further justification for using 
IMS to federate heterogeneous networks. 

For video based services, there are many scenarios that can be defined but the most hkely ones are: 

1) IPTV/IP video over BSM with terrestrial PC or phone interaction; 

2) IPTV/IP video over BSM with interaction over BSM network(s); and 

3) IPTV/IP video over BSM with interactivity over Mobile SatelUte Service. 
The most likely of these is 1), but the actual scenarios remain similar. 

With multiple codec technologies and rendering devices co-existing in today's video ecosystem, the use of IMS, as in 
the case of VOIP allows the BSM network operator to concentrate on IP transport aspects and leave issues of 
encryption, transcoding, conditional access and right management to the IPTV operator or IP content provider. 
Common identity management across heterogeneous xDSL, BSM and other terrestrial broadband networks is also an 
advantage especially when new services incorporating web services (widgets for weather and traffic) and interactivity 
(via phone texting or Twitter) are involved. In that case the IMS network acts as the meeting point and the service 
broker for all services and enables converged applications like social TV to be deployed. The use of NGN poUcy 
management also enables to decide which sessions to admit in the IPTV system based on delay or bandwidth 
restrictions. The location of the policy decisions in the BSM networks will have an influence on the IPTV and IP video 
quality of experience (QoE). 

4.3.2.3 Live/linear TV 

Live TV is currently most likely a multicast service using MPEG-4 codecs (of many profiles) over User Datagram 
Protocol directly or with the Real Time Protocol (RTP) over UDP. With IMS, the role of the BSM operator is to 
allocate enough resources for the IPTV session and to control QoS elements, like overall delay, especially for 
interactive apphcations. The BSM operator does not have to deal with appUcation level requirements. 

4.3.2.4 Video on Demand (VoD) 

For BSM networks, VoD services are not greatly different than linear TV services except that VoD is more likely to 
have less stringent QoS requirements. But it is also well known that VoD will soon be a multiscreen and multinetwork 
offering. Hence the use of the IMS functions allows the BSM networks to deliver VoD services without the need to 
provide device-specific codecs and operator or content provider-specific encryption/conditional access and DRM 
services. In addition, IMS readily federate user and subscription management across the multiple networks dehvering 
VoD. 

4.3.2.5 Emergency/Disaster Services 

There are two potential services for BSM networks in emergency or disaster services: providing emergency 
telecommunications as defined in the ETSI EMTEL specifications (emtel.etsi.org) and supporting first responders 
(Government Emergency Telecommunications Services based on NGN - NGN-GETS). 

4.3.2.6 Primary Infrastructure 

The obvious use case for the BSM system for both EMTEL and NGN-GETS is for the BSM network to provide an 
instant infrastructure. For the first responders this assumes the BSM system, via the NGN infrastructure will 
interconnect to the TETRA (Terrestrial Trunked Radio) communication network for example via common gateways but 
without the need for specific management infrastructure (but eventually needing a specific security mechanism). For the 
general public the BSM network can provide, via any Internet Gateway, instant access to needed communication 
networks outside the disaster zone. 
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4.3.2.7 Infrastructure Support 

A second use case is for the BSM system to back an existing terrestrial infrastructure and provide added capacity in the 
disaster zone. This is a preventive measure to avoid the collapse of that infrastructure under additional traffic 
requirements. In both cases the NGN architecture provides a policy based resource manager that enables to allocate 
resources to priority traffic and common user management and federation across the heterogeneous operators customers 
that are now serviced by the BSM system. The IMS core function will manage subscribers independently of the actual 
BSM operator while maintaining the BSM operator control over the BSM resources. 

4.3.2.8 Smart Grid/telemetry 

While it is unlikely that a BSM network will be used to monitor individual elements of the smart grid infrastructure 
unless these are critical, the use of the BSM system for aggregated traffic is likely. In this use case, we omit the use of 
smart grid services in disaster areas which is covered in the previous clause but concentrate on a wider use case of self 
diagnostic and self healing as data management over large areas. With embedded sensor continuously monitoring the 
grid, a BSM network could act as the main transport of this data to and from management entities and control gateways. 
With IMS this data could be sent to a variety of providers without necessitating the BSM operator to manage the 
subscribers individually, only their resources, and allocate these as in the emergency case, to priority traffic especially 
in times of high demand (failure for example). 

Similar consideration could apply to other machine-to-machine (M2M) communications and critical infrastructure 
monitoring (again with interfacing to TETRA). 

4.4 Interworking requirements 

There are two fundamental ways of interconnection of the NGN with access networks (such as BSM) as well as with 
other NGN segments: 

a) Interconnection at the Service Layer - Service-Oriented Interconnection (SOIX). 

b) Interconnection at the Transport Layer - Connectivity-Oriented Interconnection (CoIx). 

Only SOIX fully satisfies NGN interoperability requirements. For SOIX, service interoperability is dependent upon the 
service or the QoS capability of the underlying Transport Layer. 

For CoIx, an interconnection is not aware of the specific end-to-end higher layer service and, as a consequence, service- 
specific network performance, QoS and security requirements are not necessarily assured, but some services may 
provide a defined level of interoperability. Further details and options are given in [5]. 



5 BSM/NGN Architecture 

In this clause the main functional elements of the BSM/NGN architecture are described with their mapping onto BSM 
functional elements. 

A general overview of the BSM-NGN architecture is given in clause 5.1 followed by specific architectures to be used 
for specific BSM scenarios in clause 5.2. 

5.1 BSIVI-Specific NGN Architecture 

Figure 5.1 illustrates the potential overall BSM integration as an access network in the NGN architecture. More detailed 
examples are given in clause 5.2. 
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Figure 5.1 : Example BSM/NGN Integration 

This configuration assumes the following: 

• The BSM system has no inherent QoS pohcy enforcement subsystem and therefore a Resource Control and 
Enforcement Fimction (RCEF) is implemented in a BSM IP Edge node (e.g. Hub ST or router) situated at the 
boimdary of the access network. 

NOTE 1: For a BSM system with an established QoS Architecture (e.g. as defined in [3]) an Access Function that 
is essentially a protocol translation between the QoS signalling in the BSM system and that of the NGN is 
required; the BSM system uses the IMS as a b/w broker; for the NGN the BSM network is an access 
network. 

• Application clients in the UE communicate directly with entities in the NASS, Service Control and 
Applications. 

NOTE 2: Otherwise the UE may communicate indirectly with these entities via an Access Relay Function (ARE) 
implemented in the Edge node). 

• A Core Border Gateway Function (C-BGF) is implemented in a Core Border Node sitting at the boundary 
between the access network and a core network, at the core network side. 

NASS and RACS functions in the Transport Stratum may be logically distributed between access and core networks, 
and between visited and home networks. In the scenarios below the NASS and RACS are shown in the access network 
for convenience. 

NOTE 3: the interfaces between the BSM network and NGN service control and management functions are 

attached to the NCC, NMC and to the RCEF(s) above the SI-SAP, and hence no dedicated primitives are 
needed across the SI-SAP. 



5.2 Scenarios 

A number of scenarios are possible in which the BSM network may be integrated with the NGN with varying 
complexity and capabilities to match short term or longer term objectives. Specific BSM/NGN Architecture Scenarios 
are therefore specified below in which some of the BSM service requirements of clause 4.3.2 are used to illustrate how 
these architectures can be employed. 
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A BSM QoS architecture has been defined in [3], and this could be used as a basis for QoS control in the Transport 
Stratum for the BSM network. However this type of QoS control is assumed not to be generally available and thus in 
the scenarios below only BSM networks without embedded QoS control at IP level are considered. 

IMS integration, as described in the use cases, goes beyond QoS and includes subscriber management and ancillary 
services. The proposed architecture scenarios below also highlight how the BSM subscribers will be integrated to the 
NGN in order to facilitate the network convergence that NGN was designed for and which will benefit the BSM 
network in the future. 

The most likely specific BSM/NGN Architectures are specified below. When appropriate, details will be given on how 
these architectures apply to the use cases presented in clause 4.3.2. It should be taken as a principle however that all use 
cases can be accommodated by the architectures below. 

Further potential architectural examples are given in annex C. 

5.2.1 IMS Service Access - Star network-based (1 ) 

This scenario provide a minimum set of functions, keeping complexity at a low level and making this model suitable for 
easier transition to NGN by providing dynamic QoS management as well as unified subscriber management across the 
BSM network and other NGN networks. The scenario concerns a satellite star network topology where the BSM 
network functions are concentrated around the Hub ST. All additional BSM NGN functions are in the Transport 
Stratum, and these functions have interfaces to the NGN Core Service Stratum for the control of end-to-end QoS, as 
well as to the NCC/NMC, etc. for satellite-technology-specific resource control and functionality like UE registration. 

QoS in the ST (uplink) is based on fixed packet classification as there are no relevant resource enforcement functions in 
the STs, but dynamic QoS can be implanted from the Hub on the downlink. 



CPE 




NOTE 1 : The dashed boxes within the BSM System indicate the BSIVI networl< elements. 

NOTE 2: The vertical position of entities in the above diagram does not indicate position in the OSI protocol stack, 
but only relationship with NGN strata. 

Figure 5.2: IMS Service Access with l-iub-based RCEF 

The Network Attachment Subsystem (NASS) provides registration at access level and initialisation of User Equipment 
(UE) for accessing TISPAN NGN services. The NASS provides network level identification and authentication, 
manages the IP address space of the Access Network and authenticates access sessions. The NASS also announces the 
contact point of the TISPAN NGN Service/ Applications Subsystems to the UE (the proxies and application servers that 
enable specific services). These will be used subsequently for individual subscriber sessions to be initiated over the 
BSM network without direct implication of the BSM NCC/NMC except for resource management. This is particularly 
important for session orientated use cases like the VoIP or IPTV where a large number of individual sessions with 
specific requirements will be handled by the BSM network. 

The BSM network, like a number of wireless networks needs to compress the SIP signalling over the BSM bottleneck 
resources. So while in this scenario the ST does not get involved in QoS management it will be involved in signalling 
management and compress SIP messaging over the BSM network into either BSM specifics or using standardized 
approaches like the RFC 3320 [i.6] (SIGCOMP) and its specific adaptation to the SIP protocol in RFC 5049 [i.7]. In 
addition additional adaptation functions may be required to deal with the BSM delay and its effect on signalling 
efficiency and performance. It is most likely that the ST and hub would be co-located with a BSM IMS Application 
Server implementing the Interworking Functions (IWF). These aspects are further detailed in clause 6. 
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The RACS is responsible for policy-based resource reservation and admission control (unicast and multicast). The 
RACS also supports Network Address and Port Translation (NAPT) at the edge of the BSM network and assisting in 
remote NAT traversal. Furthermore the RACS covers aspects related to the setting and modification of traffic poUcies, 
end-to-end QoS and transport-level charging. For the emergency services for example the RACS will be used to 
reassign resources in order to prioritize emergency traffic. In the IPTV use case, the RACS will assign resources to the 
converged applications as required by specific service offering. Again this can be done with minimal interaction with 
the BSM NCC/NMC. 

A Resource Control and Enforcement Function (RCEF) is implemented in the IP Edge node (Hub) in order to enforce 
traffic policies. 

5.2.1 .1 Message Flow Diagrams 

The message flow diagrams for the IMS Service Access are show below. These highlight the interactions between NGN 

and core IMS elements for UE attachment and individual sessions. It is assumed that those sessions require dynamic 
per-session resource allocations. For permanent or semi-permanent sessions resource allocation in the RACS could be 
performed at UE attachment. 
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Figure 5.3: Access Messaging Flow Diagram for IHub Architecture 
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5.2.2 IMS Service Access - Mesh network based (2) 

As a further enhancement of scenario 1, dynamic QoS packet classification can be introduced in both satellite link 
directions by modification of STs with RCEFs. This would be particularly applicable to mesh satellite networks. This 
architecture is particularly appropriate for both the emergency services and smart grid application where a local ST 
could manage and police access to the BSM network without relying on a hub making it more responsive to traffic 
demands. For the other use cases this scenario could also represent a solution to convergence between different 
networks attached to the local ST. It can provide both backhauling and access. 



CPE 




Figure 5.4: IMS Service Access with ST based RCEF 



5.2.2.1 Message Flow Diagrams 

The message flow diagram for this scenario is similar to the previous one except that now at session establishment the 
RACS communicated with the local ST RCEF hence results in more BSM network signalling. 
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Figure 5.5: IMS Service Access with ST-based RCEF 
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5.2.3 Efficient IMS Peering (3) 

Here the BSM network is used as a backbone for interconnecting isolated ISP/MSP (Mobility Service Providers) 
supporting IMS for backhauling. A BSM mesh network would suit this configuration, avoiding double hop delay. The 
satellite network operator does not need to be an IMS operator, but should provide functions to manage billing and 
dynamic QoS control via a minimum set of IMS core elements. This scenario is ideal for the use case where the BSM 
network is backing up the terrestrial infrastructure in case of emergency. In addition in the converged IPTV use case 
this architecture could provide instant connectivity between a BSM network offering IPTV and an IPTV terrestrial 
network to provide added capacity in times of high demand (world wide sport events for example). The ST as is the 
2 other architectures is also where NGN and BSM signalling merge and are adapted for carriage over the peered 
networks. 

Although simple peering between IMS networks can be provided by the BSM network without QoS, a more efficient 
and assured service is provided with QoS. The message flow diagram for this architecture is identical to that of the 
preceding architecture where the UE is replaced by a NGN entity most likely a proxy function. 




Figure 5.6: IMS Peering 



5.3 Detailed Functional Architecture 

This clause provides a short description of those elements of the BSM architecture that will require some adaptation to 
comply with the NGN/IMS architecture. Since the goal of such integration is to move user and session management 
functions towards standardised NGN functions and integrate resource management into the BSM functionality, the 
BSM elements mainly interface signalling and resource management between the BSM network and the NGN core. 

5.3.1 BSM RAGS 

The functional architecture of the Resource Admission Control Function (RACS) in the BSM network is shown in 
figure 5.7. 

The BSM Star network architecture case is shown (see clause 5.2.1). 
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Figure 5.7: BSM/RACS Architecture 



The NGN Service Layer includes an Application Function (AF), which offers services that require control of IP bearer 
resources. Examples of AFs in the case of IMS are the P-CSCF and IBCF. The AF maps the application layer QoS 
information, e.g. the P-CSCF maps parameters defined in SDP, into QoS request information to be sent via the Gq' 
reference point to the SPDF. 

NOTE: the interfaces shown are TISPAN definitions. 



The Service-based Pohcy Decision Function (SPDF) provides the Apphcation Function (AF) with a single point of 
contact. 

The Service Policy Decision Function (SPDF) acts as a final Policy Decision Point for Service-Based PoUcy control 

(SEP) for each administrative domain (e.g. BSM network) it resides in. It may also communicate with an 
interconnected SPDF located in an adjacent administrative domain for a reservation request. 

The SPDF makes policy decisions by using service policy rules defined by the network operator. The most appropriate 
service based policy to be appUed to a request from an AF or an interconnected SPDF is based on the combined 
meaning of the Requestor Name, Service Class, Service Priority, Reservation Class, or any other combination of these 
information elements contained in a transport control service request message received from the AF or from the 
interconnected SPDF. 

The SPDF hides the underlying network topology from applications and from interconnected SPDFs. This allows the 
SPDF to offer a common view to the AF (e.g. P-CSCF or IBCF) and/or the interconnected SPDF regardless of the 
underlying network topology and particular access technology in use. 



The Access-Resource Admission Control Function (A-RACF) is the version of the RACE is appropriate when the BSM 
network is employed as an access network. 

The A-RACF acts as a Policy Decision Point (PDP) in terms of subscriber access admission control, as well as in terms 
of resource handUng control. 



5.3.1.1 



SPDF 



5.3.1.2 



A-RACF 
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The A-RACF receives requests for QoS resources from the SPDF, from the RCEF or from another x-RACF located in 
the same Operator Domain. Based on these requests and policy information stored in the A-RACF, the A-RACF may 
accept or reject these requests for the transport resources within its control. 

When granting transport resource requests, the A-RACF may derive and install a lower layer traffic policy in the RCEF, 
which may include indications about the way traffic control should be handled, e.g. gate control, packet marking, or rate 
limiting control. This derivation process is preceded by the mapping of the network QoS parameters, either related to IP 
level that is usually associated with technology-independent parameters, or to a lower layer that is usually associated 
with technology-dependent parameters, as well as by the inclusion of priority indications on the service and media 
requests related to specific parameters carried in the above traffic policies. 



5.3.2 BSM NASS 



The functional architecture of the Network Attachment Subsystem (NASS) in the BSM network is shown in figure 5.8. 



The NASS comprises the following functional entities: 



Network Access Configuration Function (NACF). 



Connectivity session Location and repository Function (CLF). 



User Authentication and Authorization Function (UAAF). 



Profile Data Base Function (PDBF). 



CNG Configuration Function (CNGCF). 

These functions are described in more detail below. 




Figure 5.8: BSM/NASS Architecture 



In addition two functions may be included as part of the BSM network: 



• The Access Management Function (AMF) translates network access requests issued by the UE into a format 
that can be understood by the NASS. 

• The optional Access Relay Function (ARE) acts as a relay between the user equipment and the NASS. It 
receives network access requests from the user equipment and forwards them to the NASS. Before forwarding 
a request, the ARE may also insert local configuration information. 
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5.3.2.1 Network Access Configuration Function (NACF) 

The Network Access Configuration Function (NACF) is responsible for the IP address allocation to the UE. It may also 
distribute other network configuration parameters such as address of DNS server(s), address of signalling proxies for 
specific protocols (e.g. address of the P-CSCF when accessing to the IMS). 

The NACF should be able to provide to the UE an access network identifier. This information uniquely identifies the 
access network to which the UE is attached. The UE may send this information to applications as a hint to locate the 
CLE. 

5.3.2.2 Connectivity session Location and repository Function (CLF) 

The Connectivity session Location and repository Function (CLF) registers the association between the IP address 
allocated to the UE and related network location information provided by the NACF, i.e.: access transport equipment 
characteristics, line identifier (Logical Access ID), IP Edge identity, etc. The CLF registers the association between 
network location information received from the NACF and geographical location information. The CLF may also store 
the identity of the NASS User to which the IP address has been allocated (information received from the UAAF), as 
well as the associated network QoS profile and preferences regarding the privacy of location information. In case the 
CLF does not store the identity/profile of the NASS User, the CLF shall be able to retrieve this information from the 
UAAF. 

The CLF responds to location queries from service control subsystems and applications. The actual information 

delivered by the CLF may take various forms (e.g. network location, geographical coordinates, post mail address, etc.), 
depending on agreements with the requestor and on NASS User preferences regarding the privacy of its location. Any 
privacy information, that may indicate a level of accuracy of the location information to be delivered, is also sent with 
the actual location information. 

5.3.2.3 User Autlientication and Autliorization Function (UAAF) 

The User Authentication and Authorization Function (UAAF) performs NASS User authentication, as well as 
authorization checking, based on NASS User profiles, for network access. For each NASS User, the UAAF retrieves 
authentication data and access authorization information from the NASS User network profile information contained in 
the PDBF. The UAAF may also perform the collection of accounting data for each NASS User authenticated by NASS. 

The User Authentication and Authorization Function (UAAF) can also act as a proxy. When acting as a proxy the 
UAAF can locate and communicate with the UAAF acting as server that contains the PDBF NASS User authentication 
data. The UAAF proxy can forward access and authorization requests, as well as accounting messages, received from 
the AMF, to the UAAF acting as server. Responses received back in return from the UAAF acting as server will be 
returned to the AMF via the UAAF proxy. 

In case the Point-to-Point (PPP) is applied, the AMF terminates the PPP and translates it to signalling on the a3 
interface. The UAAF is assumed to be able to contact the NACF via an internal interface to obtain an IP address 
(UAAF and NACF are in the PPP case internal functions). The al reference point does not carry DHCP signalling, 
instead the a3 interface is used to give the IP configuration information to the AMF. 

5.3.2.4 Profile Data Base Function (PDBF) 

The Profile Data Base Function (PDBF) is the functional entity that contains NASS User authentication data (NASS 
User identity, list of supported authentication methods, key materials etc.) and information related to the required 
network access configuration: This data is called "NASS User network profile". The NASS User network profile may 
be sub-divided into sub-profiles (see figure 5.2), each of which is associated to one or more Logical Access ID. Support 
of the Logical Access ID is optional. 

The PDBF responds to queries from the UAAF on the full profile or on a particular sub-profile. In the later case, it is the 
responsibility of the UAAF (or the Proxy-UAAF) to derive a Sub-Profile ID from the Logical Access ID. 

In this release the interface between UAAF and PDBF is not specified, i.e. UAAF and PDBF are either co-located or 
connected by a non- standardized interface. 
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5.3.2.5 CNG Configuration Function (CNGCF) 

The CNGCF is used during initialization and update of the CNG. The CNGCF provides to the CNG additional 
configuration information (e.g. configuration of a firewall internally in the CNG, QoS marking of IP packets, etc.), with 
respect to the configuration information provided by the NACF. This data differs from the network configuration data 
provided by the NACF. 

The CNGCF may also handle notifications from the CNG on terminal equipment availability. The CNGCF may indeed 
provide configuration information for the TEs, indirectly via the CNG or directly to the TEs. It may also trigger 
maintenance tests and process results sent by the CNG or by the TEs. 

The CNGCF may also interface with the CLE in order to retrieve information on the CNG and on the access it is 
connected to. The information retrieved from the CLE (e.g. line identifier and/or NASS User identifier) may be used as 
input to the selection of configuration data to be dehvered to the CNG. 

5.4 Interfaces and Reference Points 

The Reference Points below (which have the properties of interfaces) are those between BSM network entities and 
NGN entities within a BSM System and assume that certain entities are integrated into BSM entities (e.g. the RCEE) as 
indicated in figures 5.1, 5.2, 5.4 and 5.6. They are aU based on the TISPAN definitions for these reference points. 



Table 5.1 



Reference 


Entities 


Use 


Point 






Re 


RCEF to RACF 


controlling the L2/L3 traffic policies performed in the transport plane, as 
requested by the resource management mechanisms, i.e. gating, packet 
marking, traffic policing and mid-session updates functionalities. 


e3 


CGNF to CNG (if in 
UE) 


used during Initialization and update of the CNG to provide the CNG with 
additional network configuration Information when these Information are not 
available over the interface el , In order to allow the CNG to access to the 
TISPAN Service/applications. 


a1 


AMF to NACF 


allows the AlVIF to request the NACF for the allocation of an IP address to user 
equipment as well as other network configuration parameters. 


as 


AMF to UAAF 


allows the AMF to request the UAAF for NASS User authentication and network 
subscription checking. 



As indicated in clause 5.1, the interfaces between the BSM network and NGN service control and management 
functions are attached to the NCC, NMC and to the RCEF(s) above the SI-SAP, and hence no dedicated primitives are 
needed across the SI-SAP. 



6 BSM Adaptation Functions for NGN 

In this clause the specific elements necessary to provide NGN interoperability in BSM networks and systems are 
defined. The goal of the clause is not to go into design details of these elements but to provide descriptions of some 
essential functional elements beyond what the previous clause defined for the management of resources and QoS. These 
include (but are not limited to) policy and resource management interworking functions, IMS interfacing and SIP 
signalling adaptation over the bottleneck resources of the BSM network. This clause also provides some of the details 
for the functionalities introduced in the use cases and the architectures. A number of these functions are system- specific 
however and involve the BSM operator business models for NGN migration. 

The following topics are addressed specifically: 

• Converged services offered by NGN/IMS as simple extensions BSM system services via: 

IWF such as resource management, QoS and policy. 

Apphcation servers (AS) for higher layer interactions such as signalling and device discovery. 

• ST/GWY modifications to support the evolution to NGN/IMS, including any specific necessary for 
transmission over the BSM network (delay, loss and bottleneck resources). 
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NOTE: While there are corresponding requirements for the User Equipment (UE) as defined by TISPAN, these 

are out of scope for the present document. 

A simple evolutionary philosophy for the BSM network functionality to be integrated with NGN/IMS can be 
summarized as: 

• Re-use the existing BSM network functions, in particular the Satellite Independent Adaptation Functions as 
described in TS 102 292 [1]. 

• Provide converged services with the same infrastructure. 

• Provide standards-based solutions. 

• Satellite mobile/fixed convergence enabled by the NGN/IMS architecture and the IMS core elements. 
The evolution should include the deployment of a BSM/NGN set of added functionality such as: 

• Policy based network management for cross-networks implementation via commercially available policy 

servers and BSM network specific IWFs. 

• SIP registrars and SIP based device discovery for interconnectivity via native BSM ST/GWY signalling or 
using conraiercially available and customizable signalhng application servers. 

• BSM user profiles derived from the IMS profiles and used to manage multiple user identities across converged 
BSM /Terrestrial networks and this without any additional requirements on the BSM operator to manage the 
subscriber functions. 

• Presence and application servers for enhanced personalization of services and value-added services like IP 
television and mobile video without needing further BSM development. 

6.1 Signalling Application Server 

The Signalling Application Server is needed to adapt the SIP signalling for transmission over the BSM network and to 
account for added delay, losses and bottleneck resources. 

The SIP message contains the end point addresses as well as the addresses of the different proxies that will handle the 
session and of the registrars that contain the functions enabling device attachment to the network. STs, GWYs and UEs 
are pre-provisioned with those addresses. All required session and service information is contained within the SIP 
"payload" using the Service Description Protocol (SDP). The SDP contains information on codec, rates and end points 
characteristics; it defines all service parameters but is not involved in the routing of the information. The underlying 
system is expected to maintain the requested connection during the session and refresh connectivity parameters as 
requested by mobility, security, etc. 

It very likely that existing BSM STs/GWYs/UEs contain SIP signalling stacks used for voice over IP. These can be 
modified for use over an NGN/IMS. However there will be also many cases where there is useful no native SIP stack 
and the BSM network signalling used another protocol. Then it is customary to develop "back to back user agents" 
essentially protocol translators to connect the BSM network to the NGN. 

The operations necessary to attach a device to the NGN network and to establish a reliable end-to-end communication 
path between source and destination, require many SIP messages in both directions. Over a BSM-network this creates 
two major challenges: 

• SIP and SDP being text based, each message can be large, create overhead and hence can utilize additional 
BSM resources. 

• Delays over the BSM segment can impair the overall quality of experience especially for converged video 
services where the synchronization of video to ancillary content is crucial. 

• Packet Losses on satellite transmission can impact the SIP signalling, leading to increased delays. 
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In a real-world deployment it would be most appropriate to locate protocol translators at the terrestrial edge of the BSM 
network. There the bandwidth-efficient BSM signalling can be translated into SIP/SDP signalling and use terrestrial 
broadband to get to its destination. However, this not being always possible there are a number of both proprietary and 
standardized SIP compression mechanisms that have been developed such as those presented in RFC 3320 [i.6] and 
RFC 5049 [i.7]. Over a BSM network these could also be complemented by mechanisms to deal with delay and loss for 
example by setting existing time-to-live (TTL) timers to higher numbers. 



We assume that the existing BSM protocols are the basis from which the NGN functionality will be implemented. The 

primary IWF development effort will be to interface existing resource management functionality to the NGN access 
elements. The BSM architecture already gives the ability to use IP protocols hence there is no need for legacy services 
gateways. 

The NASS and RACS provide policy based network management (PBNM). The BSM QoS architecture [3] provides 
policy-based QoS control functions and the IWF can be used to interface between the NASS & RACS and these QoS 

functions. 

As the network scales up the PBNM system will inform the operator of the systems actual traffic demand situations as 
an aid in system growth management and allow tailoring resource allocation accordingly. 

The relationship between RACS element and BSM resource allocation will be system and architecture dependent. Both 
on-demand and permanent resources can be allocated. An element of the IWF could also be used to monitor traffic and 
ensure that the right policies are implemented to adjust BSM capacity to match the offered traffic. 



Satellite mobile/fixed convergence, in particular service and device mobility, should be enabled by the NGN/IMS 
architecture and the IMS core elements. 

This topic is intended for further study. 



6.2 



BSM IWF 



6.3 



Mobile/Fixed Satellite System Convergence 
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Annex A (informative): 

The IP Multimedia Subsystem (IMS) 



This annex provides a short summary introduction to the main concepts of the IP Multimedia Subsystem (IMS) as 
defined in TISPAN [6]. The Next Generation Network (NGN), including the IMS, provides a unified architecture that 
encompasses and operates across multiple types of access networks and access devices. While originally developed in 
the 3rd Generation Partnership Program (3GPP) for fixed-mobile convergence, IMS is now seen as a unifying network 
architecture with the fixed and wireline services specified by the TISPAN. 

The "Core IMS" is tiie term adopted by TISPAN (in agreement with 3GPP) as a subset of the 3GPP IMS as defined 
in [i.4]. The Core IMS is restricted to session control functionalities, and excludes the original 3GPP Application 
Servers (AS) that host Access Functions (AF) and transport/media related functions such as the Multimedia Resource 
Function Processors (MRFP) and tiie IMS Media GateWay function (IMS-MGW). 

The unifying principle of IMS signalling is based on the Session Initiation Protocol or SIP. SIP is used as the IMS 
control protocol and allows creation of sessions across different network elements. It also provides a unified user-profile 
across multiple devices and access networks. Finally, it enables multi-party multi-device sessions based on SIP, for 
example a session on a BSM network and a session on a terrestrial VoIP network. Sessions can be transferred between 
native networks using Application Functions (AF) that act as user agents, translating SIP signalling into legacy 



To summarize, IMS leverages mechanisms built into SIP communications networks including: 

• Single Public user identity and authentication across multiple devices, networks and applications. 

• Uniform user authentication, capability discovery and network attachment across devices and operators. 

• Tailored services based upon the user agent capabiUties. 

• Well-known mechanisms of NAT traversal and gateway traversal. 

• Investment Protection & Common Infrastructure for all services including IP-based and legacy. 



IMS is the evolution of the core network vision, where both signalling and bearer are carried over the IP layer, 
contemplated in the early 2000s by the 3'"'' Generation Project (3GPP) and the 3GPP2 standards bodies. IMS was later 
extended by TISPAN for fixed services. It enables the attached end devices to support personalized experience 
involving simultaneous voice, data, and multimedia sessions. A key feature of IMS is that the IP network is extended all 
the way to the user equipment, making the core network access agnostic and enabling all- IP communications 
throughout. The other salient feature of IMS is that the architecture supports call or session models where sessions are 
routed to one or more Access Functions that are specific to an attached network (a BSM network for example) or a 
specific operator. IMS therefore performs largely a re-routing function that matches a user profile during a session with 
an appropriate "handler", and switches the session control over to that designated handler. 

The Core IMS functional architecture and its near neighbours in an NGN network are shown in figure A.l. The BSM 
network is represented by a Transport Processing Function. 



protocols. 



A.1 



Overview 
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Rf/Ro 




Figure A.I : Core IMS functional elements, interfaces and environment 



A.2 IMS Logical Elements 

The main IMS elements that concern the BSM network in figure A.l are as follows: 

NOTE: the MGCF, MRFC, BGCF and IBCF are focussed on legacy applications and are out of scope for the 
present document. 

A.2.1 The Call Session Control Functions (CSCF) 

The CSCF can act as Proxy CSCF (P-CSCF), Serving CSCF (S-CSCF) or Interrogating CSCF (I-CSCF). The CSCF 
establishes, monitors, supports and releases multimedia sessions and manages the user's service interactions. 

• P-CSCF: The Proxy Call Session Control Function (CSCF) is the first contact point for a device (user 
equipment or UE) in the visited or home IMS network. It behaves like a SIP proxy server, and its key 
functions involve maintaining a secure communication link with the UE, locating an I-CSCF for the UE in the 
latter's home network, enforcing Quality of Service (QoS) policy, and providing service control for 
applications and services deemed local, such as emergency services. 

• S-CSCF: The Serving CSCF provides multimedia session control and maintains a session state and can also 
serve as a registrar. It is located in the home network and provides service control for home subscribed 
services for a roaming subscriber. It interacts with service platforms in the home network as well as external 
third party service platforms for support of services. 

• I-CSCF: The Interrogating CSCF is an optional component that primarily acts as a topology hiding gateway so 
the S-CSCFs are not directly exposed to outside networks. During registration flows, it also assists in locating 
an appropriate S-CSCF in the home network for the UE, based on the subscriber capabilities downloaded from 
the Home Subscriber Server (HSS). 

An important point to note here is that the above entities represent a 'functional' description of IMS components, and 
this need not imply an identical 'physical' break-up of components during architecture design or implementation. 
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A.2.2 Media Gateway Control Function (IVIGCF) 

The Media Gateway Controller Function (MGCF) provides the ability to control a trunking media gateway function 
(T-MGF) through a standardized interface. Such control includes allocation and de-allocation of resources of the media 
gateway, as well as modification of the usage of these resources. The MGCF communicates with the CSCF, the BGCF 
and circuit-switched networks. The MGCF performs protocol conversion between ISUP and SIP. It also supports 
interworking between SIP and non-call related SS7 signalUng (i.e. TCAP-based signalUng for supplementary services 
such as CCBS). 

In case of incoming calls from legacy networks, the MGCF determines the next hop in IP routing depending on 
received signalling information. 

This functional entity is identical to the MGCF defined in (3GPP) TS 123 002 [i.4] except that in addition it supports 
TCAP interworking. A node implementing this functional entity in an NGN network and a node implementing it in a 
3GPP network may differ in terms of supported resources (e.g. codecs) and configuration. 

A.2.3 IVIultimedia Resource Function Controller (MRFC) 

The Multimedia Resource Function Controller (MRFC), in conjunction with an MRFP located in the transport layer 
provides a set of resources within the core network for supporting services. The MRFC interprets information coming 
from an AS via an S-CSCF and control MRFP accordingly. The MRFC, in conjunction with the MRFP, provides e.g. 
multi-way conference bridges, annoimcement playback, media transcoding, etc. 

A node implementing this functional entity in an NGN network and a node implementing it in a 3GPP network may 
differ in terms of supported resources and configuration. 

A.2.4 Breakout Gateway Control Function (BGCF) 

The Breakout Gateway control function (BGCF) determines the next hop in SIP routing. This determination may be 
based on information received in the protocol, administrative information, and/or database access. For PSTN 
terminations, the BGCF selects the network in which PSTN breakout is to occur and - within the network where the 
breakout is to occur - selects the MGCF. 

A node implementing this functional entity in an NGN network and a node implementing it in a 3GPP network may 
differ in terms of configuration (e.g. breakout criteria). 

A.2.5 Interconnection Border Control Function (IBCF) 

An IBCF provides apphcation specific functions at the SIP/SDP protocol layer in order to perform interconnection 
between two operator domains. It enables communication between IPv6 and IPv4 SIP appUcations. network topology 
hiding, controlling transport plane functions, screening of SIP signalling information, selecting the appropriate 
signalling interconnect and generation of charging data records. 

Based on local configuration, the IBCF may perform transit routing functions. 
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Annex B (informative): 
BSM/IMS Procedures 

B.1 ST Attacliment and Initialization 

This clause describes ST attachment and initialization in a NGN context. At a high-level it includes the following high- 
level functions. 

• ST Setup and Configuration, especially with respect to the specification of Identity Credentials (independently 
of any user specific identification - at this stage the ST acts as an IMS CPE). 

• ST Network Attachment - procedures related to obtaining Layer-3 connectivity to an IP network as well as any 
necessary network-driven host configuration information. 

• ST Service Discovery - procedures related to discovering services that may be available to the CPE. 

The Attachment and Initialization procedures should, to the extent, possible leverage existing mechanisms that are well 
defined ETSI TISPAN, ITU 3GPP and IETF. 

B.1.1 SIP Usage 

The Session Initiation Protocol or SIP [i.5] is now associated with voice communication services. But the protocol was 
historically designed for a variety of media services. Moreover, driven in large part by the requirements associated with 
IP-based communication services, SIP has been extended over the years to address many of the same requirements 
currently facing many next- generation Internet applications and was standardized as the signalUng for the IMS. It 
provides the session service and device discovery, setup, policy and QOS signalling and some stream control across 
platforms. Hence, some of the key advantages of using NGN/IMS for the BSM network, hence a standards based 
approach, include important service enablers. In general, in order for a BSM ST to receive and consume IP services, 
several of prerequisite condition must be met. Specifically, the ST must have network connectivity and have the ability 
to communicate with service providing elements within the network. 

• The ST must be configured with any necessary identity credentials and have either already registered its 
identity with a BSM service provider or be prepared to do so upon activating a service. 

• The ST must have knowledge of the available service and some indication of which services it intends to use 
and to offer to its own attached devices (the ST could be a IWF for the attached devices). 

• The ST must have all the information needed to activate the NGN/IMS services it intends to use. 

This is usually provided by NOC applications (and possible satellite dependant) that are outside the scope of the present 
document. These conditions must generally be maintained throughout the course of service consumption, in a typical 
scenario they will first be achieved upon the act of booting (or otherwise initializing) the physical device that constitutes 
the ST. The term 'attachment and initialization' is used to refer to this initial set of activities that prepare a ST to receive 
and consume IP services. 

B.1 .2 ST Attachment and Initialization Overview 

Figure B.1 illustrates an overall model for ST Attachment and InitiaUzation. This model identifies the main activities 
and actors associated with ST attachment and initiaUzation. 
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Figure B.I : A highi-level model of the ST attachment and initialization process 



The generic participants in the ST Attachment and Initialization include: 

• ST: represents the software and hardware elements of the physical device. 

• Dynamic Host Configuration Server: the entity with which the ST interacts in order to perform Layer-3 
network attachment; for the BSM network it will most likely be an element within the BSM Network 
Provider's domain. 



• Service Registrar: a logical entity that is capable verifying the identity credentials of the ST. In deployment 
scenarios that involve the use of a service-signalling network (such as SIP/IMS), it may be necessary for the 
ST to register with a Service Registrar before using the service-signalling network (IMS) to contact other 
service elements. In the context of a SIP/IMS network, the Service Registrar corresponds to a SIP registrar. 

• Domain Name Server(s): the servers that provide Domain Name Services according to the IETF standards. 
These entities are used for Domain Name Services in general, but also within the context of service discovery 
as a means to locate candidate service discovery servers. 
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• Service Discovery Server(s): they are entities with which the ST interacts to discover possible BSM services. 

• Service Delivery Server (s): the logical entities with which the ST interacts in order to activate (or initiaUze) a 
particular service. 

The major activities that constitute the ST attachment and initiahzation process include the following: 

1) ST Setup and Configuration: These are the activities associated with acquiring, setting up and configuring 
the physical ST device, itself. In general, this may include activities related to physically acquiring and 
connecting a device to a network, configuring settings and user preference on the device, and establishing a 
service relationship (accoimting and billing) with one or more service providers. 

2) Network Attachment: These are activities associated with establishing Layer-3 connectivity to the IP- 
network. Through these activities the ST will acquire a network address and all associated information needed 
to transmit and receive IP packets. In addition, it will receive the necessary bootstrapping information need to 
begin using BSM network-based services. 

3) Service Registration: This corresponds to activities associated with registering the ST with a service control 
network. Specifically in SIP/IMS-based scenarios, a before the ST can use the SIP/IMS network for service 
control, it must identify, authenticate and register itself with the network. 

4) Service Discovery: This corresponds to activities associated with interacting with Service Discovery servers 
to discover information about services that may be available to the ST. 

5) Service Selection and Activation: This corresponds to activities associated with the ST selecting one or more 
services for use and interacting with network elements to activate (or otherwise initialize) the use of those 
services. 



B.2 ST Registration 

UE registration and initialization assume that the BSM network and ST have already performed network attachment 
whereby L1-L3 connectivity was established using satellite dependant protocols. As part of the initialization, the ST 
was provided with the name of the SIP server to which it must register (this corresponds to its P-CSCF) which would 
generally be accessible via the BSM network in the provider network. 

The Registration message creates a binding between the publicly known user identity or address of record and the 
specific device to be used. For IMS, a public identity corresponds to the subscriber and a private identity corresponds to 
the device. The HSS is configured with security credentials for each private identity the consumer may utihze. Thus, a 
ST (or more generally but out of scope for the present document a user device) may have a different key than is used to 
authenticate with the same subscriber's other devices. Upon successful registration it is assumed that an IP Secure 
association is made between the ST and the P-CSCF however this security model should be challenged and studied 
further. Once the IMS has completed the user registration (it is similar to the SIP-REGISTER message), it may use 
certain criteria to forward the registration on to a list of access functions that are of interest to the ST. For example, it is 
assumed that minimally the NOC is interested in the registration as to be able to approve of future resource allocations. 



B.3 The SIP-Based Service Discovery Mechanism 

This clause specifies a mechanism for BSM IMS Service Discovery (IMS-SD) based on the use of the Session Initiation 
Protocol (SIP). A BSM-CPE compliant with the present document MUST support this mechanism. The SIP Event 
Notification mechanism is used to implement the abstract Service Discovery Query and Notification functions. The SIP 
Event Notification mechanism can be used to implement both one-time queries and an asynchronous notification 
service. Assuming that such a subscription is accepted by the IMS-SD Server, whenever a change in service information 
state occurs the IMS-SD Server will send the CPE a NOTIFY message that describes the update(s). 



ETSI 



36 



ETSI TS 102 855 V1.1.1 (2011-03) 



Annex C (informative): 

Further Examples of BSIVI/NGN Scenarios 

These specific BSM/NGN Architectures complement those of clause 5. 



C.1 BSIVI Access-only scenario 

The simplest scenario is one in which the BSM network acts only as a broadband access network (in the Transport 
Stratum only) to the core NGN. No BSM functions related to the standard IMS Service Stratum are implemented i.e. no 
BSM interfaces to NASS or RACS. IMS services between the user and the core NGN would be transparent to the BSM 
network. The QoS of NGN services through the BSM network could not be assured via the IMS but only via lower 
layer methods e.g. directly between the user and the BSM network. 



CPE 




Figure C.I 



C.2 Satellite-based IMS 



This scenario implements an IMS within the satellite operator domain with a minimum set of functions to provide users 
with access to IMS services within the satellite network, without having to rely on another operator. The IMS is ideally 
closely associated with the Hub/NCC/NMC. 
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C.3 Enhanced Satellite-based IMS 

To reduce delays and to use satellite resources more efficiently compared to scenario 4, the first IMS contact point from 
the UE, the P-CSCF, is placed behind, or collocated with, each ST. 



CPE 




Figure C.3 
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